Skip to content

Conversation

@yotamofek
Copy link
Contributor

@yotamofek yotamofek commented Oct 12, 2025

changelog: [sliced_string_as_bytes]: don't fire on str[..].as_bytes()

So I ran into this in some codebase I was working on,
where the lint fired on this line:

let string: &str;
string[..].as_bytes()

So I was trying to understand the rationale behind this lint, and it says:

It involves doing an unnecessary UTF-8 alignment check which is less efficient, and can cause a panic.

This is obviously not true in the case where a RangeFull slice is being taken, since there is no UTF-8 boundary check, and no panic can be caused. So I created an exemption for RangeFulls.

Two other notes:

  1. I'm not sure the word "alignment" in the lint's description (quoted above) is really correct, should probably say "char boundary" instead?
  2. I might be missing something, but isn't there a lint for doing superfluous slice indexing, and then calling a slice method? e.g. str[..].len() or slice[..].len(), where str and slice are &str and &[T], respectively. If we had one, I would expect it to fire for the example code I quoted above.

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties label Oct 12, 2025
@rustbot
Copy link
Collaborator

rustbot commented Oct 12, 2025

r? @llogiq

rustbot has assigned @llogiq.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@ada4a
Copy link
Contributor

ada4a commented Oct 25, 2025

I'm not sure the word "alignment" in the lint's description (quoted above) is really correct, should probably say "char boundary" instead?

I mean this it's really a char boundary alignment check, so "UTF-8 alignment" isn't incorrect?

I might be missing something, but isn't there a lint for doing superfluous slice indexing, and then calling a slice method

The closest I could find is redundant_slicing? Though apparently it only lints on literally &str[..], which is why &string[..].as_bytes() wasn't linted, and (&string[..]).as_bytes() would be.

Adding support for that could be an improvement to the lint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants